Formular la especificación de una vista en forma de modelo exige disponer de un metamodelo respecto al cual ser conforme. Este es precisamente el propósito del metamodelo CVS: formalizar la estructura de los modelos descriptivos de vistas.
El metamodelo CVS presenta una estructura ortodoxa, con una clase que desempeúa el rol de clase contenedor principal (CVS_Model). Junto a ella, las principales clases del metamodelo son Category y ObjectsSpecification. La Fig. 2 muestra el núcleo del metamodelo.
Figura 1 - Núcleo del metamodelo CVS
Como se ha dicho, su papel es el de clase contenedor principal, por lo que en cualquier modelo CVS hay una única instancia suya (el contenedor principal), que contiene directa o indirectamente al resto de elementos de modelo. La clase define la asociación referencedMM mediante la que se referencia al metamodelo sobre el que se especifica el perfil.
Clase abstracta que representa el concepto de categoría definida por un perfil, bien simplemente sobre una clase (permitida) del correspondiente metamodelo o bien en forma de ensamblado. Esta distinción se corresponde con las subclases concretas que se exponen en la siguiente subsección.
Clase que representa el concepto de elemento (individual o ensamblado) que ha de aparecer obligatoriamente en todo modelo acorde al perfil. La clase define los atributos lowerBound y upperBound que representan cuántos de tales elementos han de aparecer.
La clase CVS_Model define dos asociaciones de tipo composición: categories y stipulatedObjects. A través de la primera, el contenedor principal de un modelo CVS contiene la descripción de aquellas categorías definidas por el perfil, mientras que por medio de la segunda, la descripción de aquellos elementos obligatorios. Por su parte, la clase ObjectsSpecification define la asociación category mediante la que tales objetos estipulados indican la categoría, de entre las especificadas por el perfil, respecto a la que han de ser acordes.
Figura 2 - CVS.ecore
El metamodelo CVS está diseñado con un cierto grado de laxitud en cuanto a la coherencia de los modelos conformes a él, en aras de que su estructura no sea demasiado compleja. Tal grado de laxitud es compensado mediante la especificación de restricciones de coherencia que los modelos han de cumplir para que, además de ser conformes, sean coherentes. A continuación se exponen dichas reglas de well-formedness (aún no implementadas en OCL).
Dada una instancia de la clase SimpleCategory:
La clase base referenciada ha de ser concreta.
Para cada objeto AttrImposition contenido, el atributo referenciado mediante srcAttr ha de pertenecer a la clase base.
Igualmente, el atributo referenciado a través de otherAttr también ha de pertenecer a la clase base.
No puede contener dos objetos AttrImposition sobre el mismo atributo.
Para cada objeto RefImposition contenido, la referencia apuntada mediante srcRef ha de pertenecer a la clase base.
Igualmente, la referencia apuntada a través de otherRef también ha de pertenecer a la clase base.
Ha de contener un objeto TypeSpecification XOR Nullification definido sobre cada referencia de la clase base.
La referencia apuntada a través de assignedRef ha de pertenecer a la clase base sobre la que se define la categoría instanciada.
Para el caso de una SimpleCategory no instanciable se ha de definir sobre el atributo con semántica identificativa de la clase fuente una ValueAssignmentl XOR el atributo nameSuffix posee valor.
Figura 3 - Transformación promocionadora
Figura 4 - HOT
...........
...........
Figura 5 - Modelo MAST-2 acorde a LCRMA
Figura 6 - finalModel.mast.xmi
Figura 5 - Núcleo del modelo CVS para LCRMA
Figura 6 - MAST2-LCRMA.cvs.xmi
Figura 7 - Metamodelo VRD
Figura 8 -
Figura 9 - operatorModel.vrd.xmi